@Agile86 @revitalyr Thank you for this PR as well.

I've had quite a bit of work with this one to be happy with it. To some extent that's fine and understandable, because obviously you can't be as familiar with the project as I am, but I still don't understand why you did certain things. For example:

1. I honestly don't understand the purpose of any of the changes to the KST translator that I reverted in 0e6254d...0ce1363. It looked like you didn't understand how to use the KST translator (in which case you could've asked), or you wanted to use it in a different workflow than what it's designed for, which is fine, but there wasn't any good reason to propose these changes in this PR because it has nothing to do with Rust specifically.

2. I don't understand why you thought that generating assert_eq!($actStr, 0); for expected: 'null' in a KST spec was OK (RustSG.scala:100 at 905f1f2a):

   @@ -91,11 +84,12 @@ class RustSG(spec: TestSpec, provider: ClassTypeProvider) extends BaseGenerator(
      override def nullAssert(actual: Ast.expr): Unit = {
        val actStr = translateAct(actual)
        finish_panic()
   -    out.puts(s"assertNull($actStr);")
   +    out.puts(s"assert_eq!($actStr, 0);")
        // TODO: Figure out what's meant to happen here
      }

   Did you see in any other language that we would sweep nullable fields under the rug by just storing 0 in them if they have no value? I don't think so. Even the code we generate for C++ where nullable numeric fields are indistinguishable from non-nullable numeric types (unfortunately, std::optional is only available since C++17, while we target C++98 and C++11) provides null flags so that it's at least possible to distinguish 0 and null (although in a bit ugly way). In Rust, we should of course use Option<T> instead.

   I fixed the nullAssert method in 8bdfd0c so that it expects the generated code to actually use the Option<T> type for nullable fields. Currently it doesn't, so the corresponding tests will fail to build, but that's fine. Tests should accurrately represent the current state of what actually works and what doesn't. They should pass only if the features they test fully work, otherwise they should fail. There's no point in crippling the tests to make them "green" even though the features under test don't work properly - we'd just be lying to ourselves that everything is fine when it's not.

3. Another example of crippling a test just to make it green was in ExprIntDiv - this is what it looked like before I finally regenerated it from the KST spec in 16d44c9c - https://github.com/kaitai-io/kaitai_struct_tests/blob/16d44c9c1177abd72fcfb8ffd9d17e0b86801397~/spec/rust/tests/test_expr_int_div.rs#L24-L27:

       assert_eq!(*r.div_pos_const().expect("error reading"), 756);
       assert_eq!(*r.div_neg_const().expect("error reading"), -756);
       assert_eq!(*r.div_pos_seq().expect("error reading"), 97130679);
       assert_eq!(*r.div_neg_seq().expect("error reading"), -4072);

   Again, did you see -756 and -4072 in any other language? I don't think so. I would think expr_int_div.kst:8-15 is clear enough:

     - actual: div_pos_const
       expected: 756
     - actual: div_neg_const
       expected: -757
     - actual: div_pos_seq
       expected: 97130679
     - actual: div_neg_seq
       expected: -4073

   I'm really missing what the thought process was ("no one will notice and I'll be able to say that my implementation passes more tests?"), but please don't do this. A failing test is better than faked passing one.

4. Yet another example of crippling a test, this time using #![allow(overflowing_literals)] to make the YamlInts test pass when it absolutely should not pass and the Rust compiler knows this (bf66bbe). This was actually in the compiler as well (Rust support kaitai_struct_compiler#250 (comment)) and even the runtime library had something similar (#![allow(unused)], which suppressed a bunch of warnings that had no good reason to be suppressed, see kaitai-io/kaitai_struct_rust_runtime@c7ce843).

   Come on, suppressing lints you don't like is not the solution.

5. I'm generally very skeptical about string manipulation on translated expressions (as I also mentioned in Rust support kaitai_struct_compiler#250 (review)). I'm convinced that we should always treat translated expressions as opaque strings - i.e. never attempt to "see what's inside" in any way. The reason is that string operations can't possibly understand the syntax and semantics of the expression inside the string, so it's highly unreliable, see Ruby: enum.to_i implementation is buggy due to string replacement kaitai_struct#1125 for instance. Whenever it's needed to "see what's inside the expression", pattern matching with AST objects (or perhaps data types) should be used.

   So I wasn't happy to see the string replacements that used to be in RustSG.scala in the KST translator. But surprisingly, I tried removing them and found out that they don't actually do anything (b0bd33e#diff-a6bcd12fc56efe3c133df903294fadf9330b65f2374740fa685a8946a45fc0b7). So yeah, I don't understand why they were there, but it doesn't matter now.

6. The method you used to "expect an exception" didn't really make much sense (test_eof_exception_bytes.rs:18-22):

       if let Err(err) = res {
           println!("expected err: {:?}, exception: EndOfStreamError", err);
       } else {
           panic!("no expected exception: EndOfStreamError");
       }

   First of all, this doesn't actually test the type of the error as it should (and as it does in all other languages). Second, the println! is actually useless, because Rust by default doesn't display stdout of passed tests (see https://blog.ssanj.net/posts/2023-09-24-how-to-see-stdout-when-running-tests-in-rust.html). So the above is equivalent to:

   assert!(res.is_err(), "no expected exception: EndOfStreamError");

   Which makes it even more visible that it doesn't test or indicate (so that it could be checked manually, which I don't think would be good enough, but would at least make some sense) the error type whatsoever.

   Testing the error type is actually very important - if you don't do that, you're just blindly accepting any error that may arise for any reason (which is very prone to producing false negative test results, because the test might as well just crash with some exception before it even starts, but the test result will be "all good").

   I've seen this before in Lua - some time ago, I decided to replace luaunit.assertError (which doesn't check the error type) with luaunit.assertErrorMsgMatches in bb20b5a#diff-335bd0c62964dced90d2d661679316bb2ab4be1e36b80db89f4eaee7ed94bc83. I didn't expect this change to reveal any bug, but it did - the unable to decide endianness error could actually never be thrown (such case was treated as big-endian), which I fixed in kaitai-io/kaitai_struct_compiler@f79666f. And luaunit.assertError(DefaultEndianExprException.from_file, "src/endian_expr.bin") didn't fail, because it caught an error that occurred because the arguments to DefaultEndianExprException.from_file did not match, so no parsing actually took place - the invocation was supposed to be luaunit.assertError(DefaultEndianExprException.from_file, DefaultEndianExprException, "src/endian_expr.bin").

However, I managed to correct (almost) all the wrong things I found, so I'm happy with the result. I think it's quite robust now and there should be few problems with it in the future.